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METHOD FOR DISTRIBUTING PASSWORDS 

Field of the Invention 

5 The invention relates to a method for distributing passwords. In particular, although not 
exclusively, the invention relates to a method for generating a password for use by an 
end-user device to access a remote server, where the password is retained for 
subsequent use. 

10 Background to the Invention 

The creation and distribution of end-user passwords for applications and application 
proxies is problematic. On the one hand, end-users tend to create passwords that are 
simple and short and which therefore run the risk of being uncovered by unauthorised 
15 parties. On the other hand, finding out the relationship between the end-user identities 
and their passwords is often insecure and costly. 

There are mechanisms in existence which allow the re-use of pre-existing passwords 
between different trust domains, such as Single-Sign-On solutions developed by Liberty 

20 Alliance. However, it is often necessary to rely on a third party to perform the 
authentication. When such an arrangement is employed, the service provider does not 
actively take part in the authentication. On the other hand, the password management 
performed by the service provider is not always appropriate because Ihe handling of 
passwords in application servers requires complex and costly management procedures, 

25 e.g. maintenance of the password lifetimes, overlapping password values, policies 
regarding valid values, and so on. In addition, end-users do not want to remember 
many passwords, and they tend to use the same passwords with several application 
servers, which clearly decreases the level of security. 

30 The Hypertext Transfer Protocol (HTTP) Digest authentication ftamework, as described 
in the IETF document RFC 2617, may include methods capable of generating end-user 
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passwords. For example, HTTP Digest Authentication using Authentication and Key 
Agreement (AKA), as described in RFC 3310, is a method for creating end-user 
passwords using existmg third generation (3GPP) authentication infrastructure based on 
AKA credentials stored on a tamper-resistant device, the so-called ISIM/USIM/SIM 
5 card. Details of the above frameworks can be found at http://www.ietf.org/rfcAtnil. 
Even though HTTP Digest AKA provides a flexible way to gen^ate fresh passwords 
without user involvement, it does not include a standard way to delegate these 
passwords to third parties, such as application servers or proxies. Furthermore, HTTP 
Digest AKA assumes that the passwords can only be used once. 

10 

Statement of the Invention 

It is an object of the invention to overcome or at least mitigate the above problems. In 
particular, it is an object of the present invention to delegate the passwords generated 
15 using HTTP Digest AKA to third parties so that the passwords can be securely used for 
subsequent authentication. 

These and other objects are achieved by the initial authentication being done between 
the end-user device and its home network using HTTP Digest with an algorithm capable 

20 of generating passwords, for example HTTP Digest AKA, During the initial 
authentication, the home network initiates a process in which the new password is 
linked to the identity of a third party, such as an application server or a proxy, and to a 
new temporary end-user identity for that third party. The end-user device and the third 
parly can start using the new password and related identities using HTTP Digest as an 

25 authentication method. 

In accordance with one aspect of the present invention there is provided a method of 
generating a password for use by an end-user device (UE) to access a remote server, 
comprising: 

30 sending a request for access from the UE to tiie remote server; 

creating a temporssuy identity for the UE; 
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sending to an authentication node in the UE's home network details of the 
request for access; 

at the authentication node or the remote server, generating a Hypertext Transfer 
Protocol (HTTP) Digest challenge using an algorithm capable of generating end-user 
5 passwords, including details of the temporary idenlily of the UE; 

at the UE, generating a password based on the HTTP Digest challenge, said 
password being associated with the identity of the remote server and the identity of the 
UE;and 

storing the password and the temporary identity of the UE at the UE. 

10 

The algorithm for generating end-user passwords is preferably HTTP Digest 
Authentication and Key Agreement (AKA), although it will be appreciated that oflier 
algorithms may be used- 

15 Preferably the identity of the remote server is sent to the autiientication node, enabling 
the generation of the HTTP Digest challenge to include the identity of the remote 
server. The identity of the remote server is preferably also stored at the UE. 

The temporary identity of the UE is preferably created at the remote server. 

20 

In one embodiment, the step of sending details of the request for access to the 
authentication node may iQcIude redirecting the request for access to the authentication 
node. The HTTP Digest challenge may then be generated at the authentication node 
and sent ftom the authentication node dkectly to the UE. The password is preferably 
25 stored at the autiientication node. 

After the password has been generated the UE is preferably authenticated at the 
authentication node and the request for access redirected from the autiientication node 
back to the remote server. 



30 
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La an alternative embodiment, the step of sending details of the request for access to the 
authentication node may include the remote server contacting the authentication node 
directly- The HTTP Digest challenge may be generated at the authentication node and 
sent from the authentication node to the remote server. Alternatively, the remote server 
5 may generate the HTTP Digest challenge. The HTTP digest challenge is then sent 
direcfly from the remote server to the UE. 

A HTTP Digest AKA challenge password may be included in the information sent from 
the authentication node to the remote server, enabling the UE to be authenticated at the 
10 remote server. Alternatively, the UE may be authenticated at Ihe authentication node 
and an authentication result returned to the remote server. 

The methods described above result in a password, associated with the identity of the 
UE and the remote server, being stored at the UE and the authentication node or remote 
server. This enables subsequent access from the UE to the remote server without the 
need to generate a ftirther password. In accordance with a further aspect of the present 
invention there is provided a method of accessing a remote server from an end-user 
device, the method comprising: 

generating and storing a password using a method as described above; 
sending a request for access from the UE to the remote server; 
at the remote server, generating a HTTP Digest challenge mcluding details of 
the identity of the remote server and temporary identity of the UE and sending the 
challenge to the UE; and 

at the UE, sending an authentication response including the temporary identity 
of the UE and a proof of possession of the password to the remote server. 

If the password is not stored at the remote server, it may be necessary to send an 
authentication request from the remote server to the authentication node. The password 
may then be sent from the authentication node to the remote server, enabling 
30 authentication of Ibe UE at the remote server. Alternatively, the UE may be 
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authenticated at the authentication node and confinnation of authentication sent fixjm 
the authentication node to die remote server. 

Brief Description of the Drawings 

5 

Figure 1 is a schematic illustration of a network. 

Figure 2A illustrates a sequence fijr password generation and identity agreement 
between an end-user device (UE) and s^lication server. 

10 

Figure 2B illustrates an alternative sequence for password generation and identity 
agreement between an end-user device (UE) and plication server. 

Figure 3 illustrates the sequence involved in the use of a new password. 

15 

While the invention is susceptible to various modifications and alternative forms, 
specific embodiments thereof have been shovra by way of example in the drawings and 
will herein be described in detail. It should be understood, however, tiiat tiiis 
specification is not intended to limit the invention to the particular forms disclosed 
20 herein, but on the contrary, the intention is to cover all modifications, equivalents, and 
alternatives felling wifliin the scope of the invention, as defined by the appended claims. 

Detailed Description of flie Preferred Bi nhnriimant 

25 Figure 1 illustrates a typical arrangement in which an end-user device (UE) 101 
connected to a home network 102, e.g. a Universal Mobile Telecommunications System 
(UMTS) network, wishes to access an application server 103 connected to a flurther 
network 104. The UE 101 incorporates a tamper-resistant device such as an IP 
MuMmedia Services Identity Module (ISIM) on which information can be stored. 

30 According to tiie HTTP Digest Authentication and Key Agreement (AKA) firamework a 
shared secret is established beforehand between the ISIM of the UE 1 and an 
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authenticator 105 in the home network 102. The secret is stored in the ISIM of the UE 
101. 

The authenticator 105 produces an authentication vector, based on the shared secret and 
5 a sequence number. The authentication vector contains a random challenge, a networic 
authentication token, an expected authentication restdt, a session key for integrity check, 
and a session key for encryption. The authentication vector is downloaded to the 
application server 103. The application server 103 creates an authentication request 
containing the random challenge and the network authenticator token, which is 
10 deUvered to the UE 101 . 

Using the shared secret and the sequence number, the UE 101 verifies the network 
authentication token contained in the authentication request with the ISIM. If the 
verification is successftil, the network has been authenticated. The UE 101 then 

15 produces an authentication response, using liie shared secret and the random challenge, 
and delivers this to the application server 103. The application server 103 compares the 
authentication response received from the UE 101 with the expected response received 
from the authenticator 103. If the two match, the user has been successfiilly 
authenticated, and the session keys in the authentication vector can be used for 

20 protecting further communications between the UE 101 and the application server 103. 
However, the next time the UE 101 wishes to access the application server 103 the same 
procedure must be followed to authenticate the network and obtain session keys; there is 
no mechanism to store a password for future use by the UE 101. 

25 Figure 2A shows one embodiment of a system for authenticating the UE 101 to the 
application server (AS) 103. In the first phase the UE 101 is authenticated using HTTP 
Digest AKA, and the created password is tied to the identities of the application server 
103 and the UE 101. In order to understand the processes shown in Figure 2A it is 
necessary to define two concepts used in the HTTP Digest authentication framework. 

30 
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A 'realm' is a string which indicates to the tJE 101 which usemame and password to 
use. This string contains at least the name of the authentication centre 103 and might 
additionally indicate Ihe collection of users who migjit have access. An example might 
be "registered iisers(Saiome.com" . In the contejct of 3GPP/AKA, tiie reahn of the home 
5 networic is typically stored in the SIM/USIM/ISIM card of Ihe UE 101. 

A 'usemame' is the user's name in the specified realm. This string is used by the 
application server 103 to find the correct password for the user. In the context of 
SGPP/AKA, the usemame used with the home network is typically stored in 

10 SIM/USIM/ISIM card of the UE 101. In most cases, the usemame is the same as the so- 
called Private Identity (IMPI), A 3GPP usemame identifies the siAscription, and for 
Ihis reason the passwords are specific to the end-user device rather than to the real end- 
user. In a normal HTTP authentication firamework, the usemame and password are 
typed in by the end-user, but m the context of 3GPP/AKA tiiese fields are automatically 

15 filled by the UE 101. 

As shown in Figure 2A, in the first phase the UE 101 and application server 103 do not 
have a shared secret. The UE 101 is mitially authenticated usmg HTTP Digest AKA, 
and the created password is tied to the identities of the UE 101 and application server 
20 103. The procedure has the following steps: 

la) The UE 1 sends a HTTP request (typically HTTP GET) to tiie application server 
103. 

25 2a) Since fbe application server 103 and UE 101 do not have a shared secret, the 
application server 103 redirects the request to the auflienticator 105. Before redirecting 
the request, the application server 103 may define a new tenaporary usemame for the 
UE 101. The application server 103 includes this usemame and its own identity 
information in tiie request The identity information is typically encoded mto the URI 

30 parameter in some standard formal^ e.g. "usemMne@realm". 
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3a) The aufhenlicator 105 checks to see if the application server 103 is authorised to 
do HTTP re-direction and request a new HTTP Digest AKA password for the UE 101. 
If this is the case, then the authenticator 105 takes the identity infonnation from the 
request, and encodes this information in a HTTP Digest AKA challenge, which is sent 

5 to file UE 101. In one embodiment the authenticator 105 puts the identity information 
in the so-called "server data" of HTTP Digest AKA nonce, as described in RFC 3310. 
By including the identity m the challenge, the authenticator 105 can be sure that the 
identity of the application server 103 or the temporary identity of the end-user cannot be 
changed by any party (such as an attacker) between the UE 101 and authenticator 103, 

10 because the challenge is returned back to the authenticator 105 in the next message, 

4a) The UE 101 auflienticates the network (as defined in the standard AKA 
protocol) and generates a new password based on the HTTP Digest AKA challenge. 
The UE 101 stores locally the identity of the application server 104 and the newly 

15 generated password, to be used later for mutual authentication with Ihe application 
server 103. If the challenge included also a new temporary 'usemame' generated by the 
application server 103, this usemame is also stored with the password and the 
application server 103 identity. Both the application server and UE identities are 
encoded in the HTTP Digest AKA challenge, e.g. using the format ''usemameCgreahn". 

20 The UE lOlsends the authentication response to the authenticator 103. 

The new 'usemame' is marked as a temporary usemame by the UE 101. This usemame 
and related HTTP Digest AKA password is removed when a new 'usemame' and 
password are generated for the same reahn. If the challenge does not include a new 
25 temporary usemame, then the existing usemame can be re-used. 

5a) The authenticator 105 authenticates the UE 101, and if successftd, stores the 
new password and tiie identities of the UE 101 and the application server 103 to be used 
later. The request is redirected back to the g^jplication server 103, 
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If appropriate, the application server 103 may trust the initial authentication performed 
by the authenticator 105. If the aufhenticator 105 is not perceived to be secure, the 
application server 103 may also re-challenge the UE 101 now using the newly generated 
password. This time, HTTP Digest AKA is not used for authentication. Instead, HTTP 
5 Digest with some other algorithm is used, e.g. MD5 can be used, as described in RFC 
2617. 

Figure 2B shows an alternative embodiment of a system for authenticating the UE 101 
to the s^jplication server (AS) 103. The first phase is performed using a different 
10 procedure, having the following steps: 

lb) The UE 1 sends a HTTP request (typicaUy HTTP GET) to the application server 
103. 

15 2b) Since the application server 103 and UE 101 do not have a shared secret, the 
application server 103 requests a HTTP Digest AKA authentication challenge directly 
from the authenticator 105. As in the previously described embodiment, the request 
may include the identity of the application server 103 and a new temporary identity of 
the UE 101. 

20 

3b) The authenticator 105 checks to see if the application server 103 is authorised to 
request a new HTTP Digest AKA password for this UE 101 . If this is the case, then the 
authenticator takes the identity of the application server and the temporary identity of 
the end-user (if present) from the request, and encodes this information in the HTTP 

25 Digest AKA challenge as in Ihe previously described embodiment. Altemadvely, the 
application server 103 may also include this information to the challenge in step 4b 
described below. Identity information is encoded in some standard format, e.g. 
usemame@realm or temporaryjusemame@remotejrealm. Information needed by the 
application server 103 to create the HTTP Digest AKA challenge is sent back to the 

30 application server 103. If these parameters include Ihe HTTP Digest AKA password, 
then process steps 6b) and 7b) below may not be needed. 
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4b) The UE 101 is challenged by a HTTP Digest AKA authentication challenge. The 
appKcation server 103 may add the application server and end-user identities to the 
authentication challenge before sending tihe challenge to the UE 101. However, in this 
5 case, the ^plication server 103 must be the end-point for the authentication, and 
possess the HTTP Digest AKA password. 

5b) The UE 101 authenticates the network (as defined in standard AKA protocol) 
and generates a new password based on the HTTP Digest AKA challenge. The UE 

10 stores locaUy the identity of the application server 103 (e.g. the "realm"), the newly 
generated password, and fhe new temporary 'usemame' for itself (if present) to be used 
later by the application server 103 for mutual authentication with the application server 
if present The UE 101 sends the authentication response to the application server 
103. As in the previously described embodiment, the UE 101 marks the potential new 

15 'usemame' as temporary usemame. 

6b) If the application server 103 did not receive the end-user password in step 3b 
above, it now requests the authenticator 105 to perform the authentication. 

20 7b) If the application server 103 did not receive the end-user password in step 3b 
above and it requested authentication in step 6b, tiie authenticator 105 authenticates the 
UE 101, and returns the appropriate result to the application server 103. The 
authenticator 105 may also send the end-user password to the application server 103 at 
this or some later stage. 

25 

8b) If the UE authentication was successftd, the service is delivered to the UE 101 - 

Following either of the procedures described above with reference to Figure 2A or 
Figure 2B results in the ^plication server 103 and UE 101 having a shared secret. The 
30 next time tiiat the application server 103 needs to authenticate the UE 101 (which may 
be directly after the previous procedures, or after some longer period of time, e.g. the 



wo 2005/002166 



PCT/EP2004/051233 



11 

next time iJie UE 101 contacts the application server 103), the procedure is as shown in 
Figures. 

Ic) The UE 101 sends a HTTP request (typically HTTP GET) to an appHcation 
5 server 103. 

2c) Since the application server 103 and the UE 101 have now a shared secret, the 
application server 103 challenges the UE 101 with a HTTP Digest chaUenge. The 
challenge includes the identity of the application server 103 in the •*reabn" parameter, 

10 

3c) The UE 101 sends an authentication response (typically in HTTP GET request) 
back to the application server 103 using the new temporary 'usemame' and password 
for the application server 103 created during the previous phase (described above with 
reference to Figure 2B or 2C). If the new temporary usemame was not created, then the 
15 normal AKA specific usemame is used. The UE 101 uses tiie "reahn" parameter to 
identify the correct password. 

4c) If the application server 103 possesses the end-user password, this step and the 
following step (5c) are not needed. If the application server 103 does not possess the 
20 end-user password, then the application server 103 requests from the authenticator 105 
(or some olher network entity (not shown) where the authenticator 105 has stored the 
UE specific password), for authentication. 

5c) There are two different possibilities at this stage. The authenticator 105 may 
25 take care of the authentication on behalf of the plication server 103. in this case, the 
application server 103 does not need to know the password, and the authenticator 
simply returns information to the application server 103 as to whether or not 
authentication was successful. Alternatively, the authenticator 105 may send the 
password to the application server 103, which then pCTfoncs the authentication. 

30 

If the authentication was successfid, the AS delivers the service to the UE. 
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It will be appreciated that variations from the above described embodiments may still 
fall within the scope of the invention. For example, as noted in RFC 2617, the 
authenticator does not actually need to know the user's cleartext password. As long as 
5 the digested value of the usemame, realm and password is available to the server^ the 
validity of an authorisation header may be verified. 
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CXAIMS: 

1 . A method of generating a password for use by an end-user device (UE) to access 
a remote server, comprising: 

5 sending arequest for access ftom the UE to the remote server; 

creating a tempore identity for the UE; 

sending to an authentication node in the UE's home network details of the 
request for access; 

at the auflientication node or the remote server, generating a Hypertext Transfer 
10 Protocol (HTTP) Digest challenge using an algorithm capable of generating end-user 
passwords, including details of the temporary identity of the UE; 

at the UE, generating a password based on the HTTP Digest ch^enge, said 
password being associated with the identity of the remote server and the identity of the 
UE;and 

1 5 storing the password and the temporary identity of the UE at the UE. 

2. A method as claimed in claim 1, wherein the algorithm capable of generating 
end-user passwords is HTTP Digest Authentication and Key Agreement (AKA). 

20 3- A method as claimed in claim 1 or 2, further comprising sending the identity of 
the remote server to the authentication node, wherein the step of generating the HTTP 
Digest challenge includes using the identity of the remote server, and wherein the 
identity of the remote server is stored at the UE. 

25 4. A method as clahned in claim 1, 2 or 3, wherein the temporary identity of the 
UE is o'eated at the remote server. 



30 



5. A method as claimed in any preceding claim, wherein the step of sending details 
of the request for access to the authentication node includes redirecting the request for 
access to the authentication node. 
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6- A meliiod as claimed in claim 5, wherein the HTTP Digest challenge is 
generated at the authentication node and sent firom the authentication node directly to 
fheUE. 

5 7- A method as claimed in claim 5 or 6, wherein the password is stored at the 
authentication node. 

8- A method as clahned in claim 5, 6 or 7, further comprising authenticating the 
UE at the authentication node and tedirecting the request for access from the 
10 authentication node back to the remote server after the password has been generated. 

9. A method as claimed in any of claims 1 to 4, wherein the step of sending details 
of the request for access to the authentication node includes the remote server 
contacting the authentication node direcfly. 

15 

10. A method as claimed in claim 9, wherein the HTTP Digest challenge is 
generated at the authentication node and sent from the authentication node to the remote 
server. 

20 11. A method as claimed in claim 9, wherein the HTTP Digest challenge is 
generated at the remote server. 

12. A method as claimed in claim 10 or 11, finlher comprising sending the HTTP 
digest challenge from the remote server to the UE. 

25 

13. A method as claimed in claim 1 1, further comprising including a HTTP Digest 
AKA challenge password in the information sent from the authentication node to the 
remote server and authenticating the UE at the remote server. 
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14. A method as claimed in any of claims 9 to 12, further cornprising authenticating 
the UE at the authentication node and returning an authentication result to the remote 
server. 

5 15. A method of accessing a remote server ftom an end-user device (UE), tiie 
method comprising: 

generating and storing a password using a method as claimed in any of the 
preceding claims; 

sending a request for access from the UE to the remote server; 
10 at the remote server, generating a Hypertext Transfer Protocol (ETTTP) Digest 

chaUenge including details of the identity of the remote server and sending the 
challenge to the UE; and 

at the UE, sending an authentication response including the temporary identity 
of the UE and a proof of possession of the password to flie remote server. 

15 

16. A method as claimed in claim 15, further comprising sending an authentication 
request ftom tihe remote server to the authentication node, sending the password from 
the authentication node to liie remote server, and authenticating the UE at the remote 
server. 

20 

17. A method as claimed in claim 15, further comprising sending an authentication 
request from the remote server to the authentication node, authenticating the UE at the 
authentication node, and sending confirmation of authentication from the authentication 
node to the remote server. 



25 
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Figure 1 
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Figure 3 



